Certain document files are not intended for editing or at minimum should not be saved over the original document file. For instance, in previous server based collaboration systems, transitioning between reading and editing modes is error prone and non-intuitive. For instance, when a user selects a file to read and not for editing, an application is launched and the document is placed in a “read-only” state. This process avoids having locks placed on document files that are mostly read and not edited. However, the confusing downside is that the “read-only” state has features that do not exhibit a “read-only” state. The title-bar reads “Read-Only”, but the file isn't truly “read-only” in the file system. For instance, typing functionality and the commands are still operative and when “SAVE” is selected or pressed, a lock for the file is retrieved in the form of a “Save As” dialog box. Thus, some features of the “read-only” state give the impression that the document file is being edited, however the document file is not really being edited until “Save” is selected. This functionality confuses users as to the reality of the state in which they are operating. Consequently, some users don't notice the title-bar, edit their long document, and press “Save” to find that another user is editing the document elsewhere.
Other scenarios that do not even involve a server are also impacted. For instance documents that are electronically signed ideally should invalidate the signature when the document is edited. However, in previous systems despite some warning dialogs, signature blocks are broken with relative ease. Another scenario where a read-only” state is not completely apparent involves information rights protected documents that permit authorized users to make changes after authentication. Therefore, an unaddressed need exists in the industry to address the aforementioned deficiencies and inadequacies.